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Workflow-based applications 
by F- Leymann and D. Roller 

A significant nu^e. of con^anies are -"^f ^^^Jj?,^^ jj.^c^S:" musf 
Ire^ffective and productive, ^""^f iJl.^^^^'^Se new applications 

be modified, ^n<i . *PP^?;'=^!^""^^'""^ter^^^^^ environment, perfoming 
typically run in a '^"trxbuted and" heterogeneous functionality 

sSgle tasks in P"-l^«^' j;2^,f'^;f,Slow!basL applications offer this 
for the supporting «"^"°"™"'^=;^*°t^eir principal advantages are 

cohesive and consistent way. 

Business re-engineering is one ^l^l^^r..^^^^^^^^^^ 

of a large number of companies. J"^^^ H ^^^^ flexible and to 

business environment that ^ting ones are changed or 

react faster. 1 New processes are defined, existing oi 
even abandoned. 

for exaB«>le, starts the appropriate ^^^"^^""^^^"^0 tie together parts 
(Sational Informtion Infrastructure Initiative) .2 

Business processes not only deal with customers; internal adna-^J-f 
processes are also business processes^ A form. An 

administrative process is the handling of ^^P^"^^ ^^^^ed to the 

another administrative process. 

one of the Key objectives of the -"-^^^-^^f /i^r.r-reffn:^::^:^''' 
minimize the time required for execution. In a well aeii 
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process, therefore, all unnecessary tasks have been elxminated, and all 
tasks are performed «ith the highest degree of parallelism possible. 
These t^^ks can be performed by different people. Coincidentally, 
different equipment with different software is used to perform the tasks. 

tS^e^sLess processes are run in a distributed and heterogeneous 
environment, 

workflow management systems (WTOSs) provide the foundation for defining 
and executing business processes. We will refer to applications built 
according to the workflow paradigm as workf low-based applications. 

The creation of workf low-based applications needs a special development 
method, which we call process-based CASE (computer-assisted software 
engineering) . The method we are proposing in this paper provides a 
consistent way of developing this kind of application. The metaphor 
fundamental to this method is the two-level programming paradigm of 
workflow technology, in which programming in the small is dellverea 
through visual builders, and programming in the large is delivered via 
business modeling tools and workflow build time. 

The next section introduces the notion of a work flow-based application by 
revealing the impact of database and workflow technology on the structure 
of applications. The subsequent section summarizes the benefits ot 
workiiow-based applications. The^. the following "^^"^ • ^'^f ^J^^^^^T^^ 
relations and synergy between workflow technology and object technology. 
The section after that outlines an application developer's wish list for 
a development environment that helps to efficiently design, implement, 
and monitor workflow-based applications, and the succeeding section 
provides a blueprint of the components of such an environment. That 
section is followed by one showing some aspects of testing of 
workflow-based applications without requiring the setup of a complex 
environment, and then a simple example of how such an environment could 
work is given. The last section outlines the transaction management 
features of a workflow management system desirable for further enhancing 
the flexibility of workflow-based applications. The paper concludes with 
a suimiary. 

The notion of workflow-based applications 

Figure 1 shows the fundamental steps in the evolution of the structure of 
application systems. As depicted in part 1 of the figure, the first 
application systems built ware large monolithical pieces of code with 
some internal structuring. The internal structuring reflected the pieces 
of infrastructure code that had to be built by the application 
developers, in addition to the pieces of code that implemented the actual 
logic of the application. 

Removal of data dependency. The lower boxes of part 1 reflect some 
pieces for accessing data. These pieces include, for exanqpie, the 
handling of data sets, such as opening and closing an account file, 
performing the actual physical input and output operations via the 
appropriate I/O routines provided by the operating system, such as 
reading an account record, or Interpreting the data retrieved according 
to some inline mapping information, such as the location and the type of 
the account number. 

Any change to the schema of the data, such as the addition of a field to 
a record or a change of access path to the data, requires all 
applications that accessed the record to be changed and the data to be 
migrated. Therefore, these applications are data dependent. 
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To reduce data dependency, each application system introduced its own 
files holding redundant copies of the "sane" data with the well-known 
consequences of Jeopardizing data consistency- 

The management of the information about the data, such as which data are 
maintained and where the data are used, is also cumbersome. This 
situation became worse over time with the increasing amount of 
information. 

As a consequence, database management systems (DBMSs) were developed, 3 
Their purpose was to support the definition and concurrent manipulation 
of data. Many changes to the data schema and access paths, for exan^le, 
can now be done without impacting the related programs. The body of data 
becomes a property in its own right; it becomes a corporate asset* 
Consequently, the structure of applications changed to the structure 
depicted in part 2 of Figure 1. 

Removal of flow dependency. The boxes depicted in the middle of each of 
the three parts are the application logic blocks that contain the actual 
application functions and business algorithms. The top boxes in part 1 
and part 2 show some pieces that are required to put these application 
logic blocks together in a form prescribed by the application. To use a 
banking application as an example^, it would include bringing the blocks 
into the correct sequence to first withdraw money from one account and 
then deposit it into another account, or passing the proper data from one 
block to the next so as to pass the amount of money to be transferred 
from the withdraw block to the deposit block, or assigning the right 
person to a task based on application-specific criteria such as the 
authority of the account owner. 

A change in the assignment of tasks to people, commonly referred to as 
staff asisignment/ 4 in the execution sequence of the application logic 
blocks, or the addition of a field to be passed between the blocks, 
requires the application to be changed. Applications are flow dependent. 

These changes are cumbersome and generally cannot be performed fast 
enough. In addition, the actual structure of the business process is not 
known to nonprogrammers . This situation becomes worse with the 
increasing demand to adapt to market needs that are changing ever faster. 

Workflow management systems were developed to help overcome these 
problems- Their purpose is to support the definition and execution of 
business processes. That means that the definition and execution of the 
appropriate control and data flow, the assignment of people to tasks, and 
the invocation of the application logic blocks are externalized. By 
definition, changes to the process can now be done without impacting the 
application logic blocks. The process becomes a property in its own 
right — it becomes a corporate asset, 5 The structure of the applications 
changes to the structure depicted in part 3. The application becomes a 
workflow-based application consisting of a model of the underlying 
business process and a set of (flow- independent) application logic 
blocks. € The abstractions of the elementary pieces of work in a business 
process are called activities; the concrete realizations of these 
abstractions at process execution time are referred to as activity 
implementations , 4 The application logic blocks correspond exactly to 
these activity implementations in a WFMS environment. 

The capability of the workflow management system to support the 
definition and execution of control and data flow, the assignment of 
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activities to people, and the invocation of the activity implementations 
associated with such an activity is not limited to splitting up large 
monolithical applications. it allows the various activities to be 
distributed to different computers with different systems. Different 
systems may mean different operating systems supported by the same 
workflow management system or may mean different workflow management 
systems. Workf low-based applications are, therefore, by nature 
distributed, heterogeneous applications . 

The fundamental benefits of workflow-based applications 

In this section the following four fundamental benefits inherent to 
workflow-based applications are discussed: 

o Flexibility in changing the model of the underlying business process 

o Integration capabilities for even disparate applications 

o Reusability of activity in^^lementations and process models 

o Scalability of application development and execution 

Flexibility. The first benefit is based on the two-level programming 
paradigm underlying workflow-based applications . The specification of 
all flow relation information is, as was already described, separated 
from the specification of the logic of the application functions, that 
IS, the algorithmic aspects of the application. This separation allows 
the model of the process underlying the subject applications to change 
without affecting the associated activity in^jlementations. It is the 
tJSy'""^'''' reason why enterprises are investing in workflow technology 

Integration. The second benefit is based on multiple features. 

First, the ability of a wms to persistently store the workflow-related 
execution context of each activity implementation (that means the 
contaanersj) and share it between different activities via the supported 
data flow features allows for an integration of activity implementations 
that IS different from the current standard approach of accessing a joint 

Second, transaction features tailored toward support in WFMSs have been 
proposed (for example, see References 7, 8, 9, 10, and 11) to especially 
allow the integration of activity implementations that are accessing 
different DBMSs into atomic units (in the sense of "all or nothing") or 
compensation units (in the sense of "joint compensation") ; see the last 
section for more details. 

Third, the heterogeneity feature currently being worked on by the 
Workflow Management Coalition (WfMC) 12 and NIIIP2 strives toward support 
of cross-enterprise business processes. That support means that each 
application part may even be managed by a different vendor's WFMS. The 
goal is to enable "virtual enterprises" not only by supporting 
cross-enterprise sharing of data based on the STEP (STandard for the 
Exchange of Product definition data) standard (for example, see Reference 
13), but also to share business processes across enterprises and to 
enable interoperation of workflow management systems. 

Reusability. The third benefit is based on the structure of 
workflow-based applications themselves. As elaborated earlier, activity 
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««hp1s are tvpicallv flow-independent and 
implementation, for P^^^^^^^^jf i^gf (wSh the final consequence that 
free of assumptions about their ^J^^ ^ ^^e last section) . 

external "ansaction mechanics are^need^^ 

Therefore, a P"^^=^i"/*=^i7bJth^he activity implementation and the 

different process models. ir do standard for "invoked 

worKf low »«nager "^P^^ Ji^J^^I^^LtSon can ultimately be used in 

applications, "12 the ^'^^^^'-''^ 3^ tH- exploitation of workflow 

niny different WFMSs. As a result, ^he exploi ^^^^^^tations (for 

on «orK£lo» wchnoloM is independent of it. 
r„«..™.re, tH..e i. . =t.o„, d»-nd^t n^^r.oJ^S^i^'" 
iI,pJei»ent.tion» th»t «" ""i^"" ' ^ ,„d bottom-up inodelina o£ 

;'^.:::'"zi\X's "fiir fHe^::s,. o. p-ce,. ^.i. 

subprocesses - 

such as the Object Management Group (OMG) and the 
industry consortia such as ^ various vendors, are 

Object Delinition Alliance <°°^> '^^.^"/Jhe purpose of being able to 
currently defi"^'^^ reusable components for the p^ expectation is 

construct applications out °* P"f "^^^l^J^s off-the-shelf 
that these components will eventually be sola as oi 

components . 

The formation of a joint -or. fou, of .^^^ r.?.^SL'~n boused 
these components will be spe="j;«^ ^^.J^^rp^ocess models. This will 
SrSnXr;=- pfraS^^-rfTorkllow-based applications. 

Similarly, industry interest ^ll^^r^^^^lfll^^^^^^^^ 

specifying de facto standards for models can be reused in 

particular application TJ"! ^^^H" processes. In this 

particular as subprocesses in ^"terprise specific pr ,oft„are, SAP 

Context, it is interesting to note that vendors of stand ^. ^ 

with R/3-15 for example, are -""^f iy/!J*=^^i;?o^*'^LgiSent systems 
models of business processes, '~»''^"^ u"„f.^jJe p^o«ss model, 
so that the application performs according to th« ^ ^ i„ 

Workf low-based applications will thus very lixeiy pi y 



this area, too. 



^^^^^^^^^ ^ 

large applications, such as the "'d" Pf first glance, one would 
involving processes of ""^'^J^^^^PP^^^^^;^ deJids specialized workflow 
assume that covering such a ^'oad spectrum demanassp .^^^^ 

management systems that have -^^-^^^'^"^rthe development groups of 
However, that is not the case. It ^^J^ ^ygtem architecture and 

application development. The ^ievelopment of worKflov^ 
provides scaling through the underlying two ^^jel prog ^^^^^^ 
the top-down process modeling capabilities, and the reuse p 
models and business objects. 
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1 1 e f i rst the development 
Developina an application in two -P-^^^J^^^y^th; Lvelopment and test of 
IZ test of the business process and 1^1°^^^^^^^^^ the application 
S^e acrivity implementations ^^^^^^^^^^^g^Sndpolnt. In P"^-"^"' 
from a design. i'^i^^^^^^t^J^.e ;ctWity Ulementations, made Pf -J^Jf 
the parallel ^-f^^P-f to tSe buri;;ess'process, provides for a faster 
by the fixed xnterraces 
development cycle. 

,he support of subprocesses aXlows the top-down J^^^^^^^^ 
p^:c:^es. First, the ^if "1--^ J^^^^^^;;,?;:::: are developed and 
Lsted, and then the ^-"^^^ji^^^J^J^rparallel development of busxness 
tested. This sequence facilitates cne h 

processes. 

development as well as activity imp 

;^plication execution. J^lZeX'.l^^^^^^ ^ 

Scilitated through the ^^^^^^'^.J^^^^t severs; workload balancing 
3Ubprocesses can be executed on ^f^^^^^.^^^^^s; dynamic invocation of 
:Sports exploitation of ^^J^;^^;^^,^i:,rr"ce";rsy provides flexibility 
activity implementations ^J^^^^f distribution of work items 

in executing activity ^""P^^f ^^^^^^^ers to be balanced, 
allows the assignment of users to servers ro 

Objects can benefit from workflows 

enterprises are investing today in object technology - tr:-;ro«ssing 
productivity Of their programmers and to enable e^^^^^^ (described in a 
professionals to build '^PP^^°**^t^Le of the benefits object technology 
Lter section) . Here we d"-"^=^°'"!°*t,^„%orJf low-based applications 
ndght gain from --"l^^'^-^J^J^^JLt vendors of standard software (like 

can be built «ithj>b3ects Note t^t ve technology (for 

SAP) are also combining object technoi gy 

example, see References 15 and 16) . 

example, if the order in which °P^"tions .^^^i^es of object 

IrTt operations can be added ^trol object. That 

technology consequently ^^^^tng of various operations. Thus 

control object encapsulates scheduling^ behavior and data must 

S rartnroTcro::: ^iLrin^-ir-e), but also ..ordering.- 

« the last proposition is ignored fllowi^^^ P"^-- 
tends to hide fragments of P^^P^^J^^^^^J^.^^on not only the objects 
iinplementations of the obDects.lT ''J^^^^ttively so does each 
S^n^elves become flow-dependent ^'^^ transitive y ^^^.^^^^ processes 
application reusing these objects ^J^^^^^^^^' described explicitly 
(King an asset by themselves) ar^ only P«tialiy ^^^ementing 

„d externalized to a ^^-f^her^coi^ "-"^"^^P-'*^^^ "^'^ 
f.j;reni-b:red ^pMon^t^at are much more flexible, 
scripting and objects. Building flow-ind^^^^^^^^^^ 

:E5:rt: L:i.^tSe^rrrfyn:mI^ - the busmess processes. . 
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invoking a method of an object. 

^en the st.tic o. a business split troj^^ 

between business objects ^^^^^^bing the use of business 

«>del may be perceived as a script P'^"!"''^'*^^ ^ime, the workflow 

Objects to reach P^^f "^J^^^ie flow S ^ontroHnd data between the 
^nagement systen. will ^llll^2\llns.o^,^r. boundaries around them as 
business objects/ wixi. ^«,.i-ain that the proper 

defined i» -"Jf ;,'^S.-^ii,^fi,rre"~ «=p^n"'l« »""^"' 

fiwem the »=el»>i l»voc.tio». of the objects. 

xt i, l^ortaot to note tKat -e ^^i^^TorvLSS"""" 

and why we think two different categories of scripting nave a r g 

exist. 

workflows in object-oriented analysis and design. ^Object technology 
TroSirmt^y Schniciues to capture the dynamic ^ehavior of an 
Application, for example, collaboration ^"^str^crJeJerthey^^^e the 

invocations of the participating objects. 

Reference 21 points out, based on this insight, that two P^i»«fPf 
SfJerent structures of such diagrams can be observed <see Figure 3 - 
?^r2 repr:s:nt centralizing responsibilities, which --^^J^f -^^f ^ 
obiect represents the global control and data flow The 

provide utilities. Such a -^--^"«„tL?SSes iLrmeSfthat 

Taci-bjecrkiSsT^-T^^^^^^^^^^ 

- S-U^nren^^^^^^^^^ ^^^^t^l^^S^ 

T^oTs Zll ty?ically encapsulate ordering^ ,ro~^;arfirk and 
:Srr^:t:uc;rrrSa:r?i^ieVsL°rn" V-- ^ stable and 

robust structure. 

one of the special strengths of workflow technology is J-^^^^Jf 
H,«difications for operation orders in an easy manner. Tnus, lu :r 
^?irirto exploit workflow technology for the implementation of fork 
structures, tLt is, for encapsulating the ordering of operations. 
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Simply, the controlling object itself becomes an instance of a process 
model that in turn describes the control and data flow between the 
affected objects. 

For this purpose, each method invocation stimulated by the control object 
becomes an activity in the process model, which finally represents the 
control object. Thus, if the method m of object o is invoked, o.m{) is 
an activity of this process model. The control connectors are prescribed 
by the time order in which messages are sent according to the message 
flow diagram- If ml is sent to ol and m2 is sent to o2 and no other 
message is sent to any other object in between, the flow of control is 
from ol.mlO to o2.m2(). Based on the structure of message flow 
diagrams, no parallelism is exploited in the process model derxved by 
this simple algorithm. Typically a design phase needs to be conducted to 
establish a more sophisticated process model. 

At run time, the WFMS will instantiate this process model/ resulting in 
an instance of the control object. By definition, there will be no 
implementation of the control object in the classical sense, for example, 
in C++: the implementation consists of the process model, which is 
interpreted on a per instance basis by the WFMS, Consequently, changes 
to the process model will immediately affect- the implementation of the 
corresponding control objects instantiated after the changes. 

A method has been proposed in Reference 6 for analyzing a message flow 
diagram in order to divide it into a collection of subdiagrams, each of 
^ich is either a fork structure or a stair structure. Fork structures 
can be transformed into skeletons of process models in a straightforward 
manner. Stair structures are natural candidates for modularization; that 
Is, they can be realized as programs or as subprocesses , 

Application developer's wish list 

The development of workflow-based applications can be facilitated by a 
new approach that helps application developers in the design, 
in¥)lementation, and testing of those applications. We call this approach 
process-based CASE to indicate that the goal of the proposed CASE method 
is to create applications that are workf low-baaed, thus implying that the 
underlying business process is externalized and managed by a workflow 
management system. This approach is different from the notion of 
process -centered CASE, where processes are used to develop applications 
and coordinate development teams. 22 In fact, process-centered CASE could 
also be applied to process-based CASE. 

First, the development of the applications should be supported with the 
set of new and evolving programming paradigms, such as visual 
programming, the construction from parts, the usage of business objects, 
binary code reuse, object orientation, and, by definition, the 
exploitation of workflow. 

o Visual programming supports the development of programs that are no 
longer performed by writing statements in a programming language. The 
program is constructed {1) by creating the advanced graphical user 
interface of the program by drawing the screen layouts on the screen, 
and (2) by visually assembling and connecting parts to define the 
behavior of the program. 

o Construction of parts is a technology to build applications from 

existing, reusable software components called parts, 23 The assembly is 
typically performed via the composition editor of the visual builder. 
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Parts provide a wide range of capabilities, from very simple functions 
through complete, highly sophisticated applications . Primitive parts 
can be combined to form more complex composite parts. 

o Business objects are becoming increasingly important as granules of 
reuse. Typical examples may be a customer business object or an 
account business object- Standardization is underway as shown earlier 
in the third section of this paper. 

o Binary code reuse is a key factor in the success of application 

development productivity. Source code reuse just will not render the 
productivity increase the software industry is looking for. Business 
objects are the main manifestation of this paradigm. 

o Workflow allows us to define, execute, and monitor applications that 
move the work to be done to the desktop of the person responsible for 
performing a piece of the overall task. 

Second, the development approach must cater to the specific 
Characteristics of workf low-based applications. It must support the 
design, in^lementation, and testing of the distribution aspects of the 
applications, in particular^ the parallel execution of tasks . 

Third, it must support openness tl^rough compliance with appropriate 
standards, including de facto standards such as CORBA (Common Object 
Request Broker Architecture) , 24 OX*E (Object Linking and Embedding) , 25 
WfMC, OpenDoc,24 and Lotus Notes**- 

Fourth, this development environment must be available on a variety of 
platforms. 

And last, the components of the development environment must be tightly 
integrated. In particular, they must provide a cohesive, seamless, and 
intuitive end-user interface. 

Development environment blueprint 

The essential components for the proposed environment are (1) a business 
modeling tool, (2) an object-oriented analysis tool, (3) a workflow 
management system, (4) a visual builder, (5) a database management 
system, (6) a database design tool, and (7) object support. Figure 4 
depicts those components that are exposed directly to the user of such a 
development system. In this section we discuss the components. 

Business modeling, A business modeling tool is one of the starting 
points for developing workf low-based applications. It is Intended to be 
used by internal or external consultants, organization specialists, or 
business re-engineering experts. IBM's Business Process Modeler, IDS's 
ARIS** Toolset, Holosofx's WorkflowBPR tool, or UBIS ' s BONAPART** are 
typical exan^les of this type of tool. Their main focus is on allowing 
the business experts to model processes and business objects used within 
a business process. They typically inclement a proprietary methodology 
to describe the business process. For example, the IBM Business Process 
Modeler uses an extension of the LOVEM* (Line of visibility Enterprise 
Method) methodology developed by IBM Canada for re-engineering 
corporations; the ARTS Toolset uses the ARIS methodology developed by 
scheer.26 

The usual result of such an analysis is a high-level description of the 
business process. On a conceptual level, this high-level process 
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describes the business actions and their relations, the "^^""^^^^^^^ 
units performing these business actions, and the ^"^^^J^^^ 
these business actions are working on. The level of detail depends on 
the significance of a particular item in the overall business process. A 
business object therefore could be a complete database, such as the 
payroll database, or a single column in a table, such as a state code 
used to determine which path needs to be taken within the process. 

An important function of business modeling tools is to collect metrical 
information about strategic target volumes of business objects and 
processes. This information will be refined later in the. development 
process to determine the performance characteristics of the process as 
well as the resources, both people and IT (information technology) 
resources, required to perform the process. 

In general, the results obtained via the business process modeling tool 
are not directly usable by a workflow management system to execute the 
business processes. They need further refinement in the specifications 
of IT resources, such as programs used to perform the activities, the 
topology of the system, etc. This task is performed using the build-time 
component of the workflow management system. The approach is similar to 
the one taken in the design of databases, where it starts with a 
conceptual design that is transformed into a logical design. The 
conceptual design, for example, dope as an entity-relationship model, 
provides an implementation-independent view of the data. This model is 
then translated into a logical design, such as the tables of a relational 
database system, by adding implementation-dependent information. 

How the information is handed over to the workflow management system is a 
matter of coupling the business modeling tool and the workflow management 
system. One approach is to have a common data store. A sin^jler approach 
is the generation of an interchange format that is imported into the 
workflow management system. The WfMC is standardizing this format to 
facilitate the interchange of process model information between different 
in^lementations of workflow management systems. Until this standard is 
issued, the business modeling tool must generate the workflow manager's 
proprietary exchange format, such as the FloWMark Definition Language 
(FDD of IBM's FlowMark*. The ARIS Toolset, for example, generates FDL 
from its process definitions. 

Object-oriented analysis. Another approach to the development of 
workf low-based applications is object-oriented analysis and design. As 
outlined previously, the results of the analysis could be used in 
different ways. it could be used to generate process skeletons in the 
workflow manager's exchange or, if available, in a standardized format. 
It could also provide the visual builder with the proper information to 
allow rapid creation of the activity implementations. 

Workflow build time. The purpose of the build-time con^jonent la to allow 
the user to define the processes in terms of process logic, associated 
organizational information, and IT infrastructure required to execute the 
processes. 4, 5 As pointed out earlier, this information may be derived 
from information collected by the Business Modeling Tool or the 
Object-oriented Analysis Tool. The definition of the information is 
entered via a graphical end-user interface. Typically an animated 
process graph is used to help determine the correctness of the process 
graph and the correct invocation of the programs implementing the system 
program. Analytical and discrete simulation help to determine whether 
the organization is capable of handling the workload and whether the IT 
resources are sufficient to cope with the system, database, and 
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conmiunications load. 27 

Visual building, A visual builder is a visual programzning tool that can 
help develop all kinds of applications/ including mission-critical 
applications. It allows a prograiraner to rapidly prototype and build 
applications with menu bars, entry fields, and icons. Programs are 
written simply by making connections between objects and parts. 

Workflow rim time. The run-time component of the workflow management 
system controls the execution of process instances. It allows the user 
to start, terminate^ suspend, and resume processes. It determines who 
should perform a particular activity^ puts the resulting work item onto 
the work list of the selected user(s), schedules the propejf program when 
a work item is selected and determines what activities come next after 
one has been completed, and records all these actions in an audit trail. 

Process monitoring- Processes must be monitored for various reasons: (1) 
to determine the workload of people and take proper action if the 
workload is unevenly distributed^ {2) to recognize critical situations 
vfhere work is piling up, and (3) to obtain process statistics. The 
process statistics are created from the audit trail that is automatically 
written by the workflow management system during process execution. This 
information can be used to verify the assumptions used during simulation, 
such as process creation rates, path selection probabilities, and 
activity processing time. 

Schema creation. The business objects identified during business 
modeling or object-oriented analysis are the input to conceptual data 
modeling. They represent the local conceptual schema of the application 
implemented via a business process. In general, these objects form the 
kernel entities of the enterprise data model and thus provide the basis 
for the creation of an enterprise data model through view 
integration .3,28 

The conceptual schema is transferred into a logical schema, the schema of 
the database in which the data are stored. Reference 28 outlines the 
rules for transferring an entity-relationship schema into a relational 
schema . 

A physical schema is created from the logical schema by choosing specific 
storage structures and access paths to achieve optimxim perfomance for 
the various applications. Input to the physical schema design consists 
of the transaction load and the database load. Both pieces of data can 
be derived from information collected during business modeling, workflow 
definition, and application building- 27 

Database monitoring- The activities in the databases must he monitored 
to detect porformance bottlenecks. Monitoring could trigger 
modifications of the database schemes. It is also conceivable that it. 
may impact the structure of the business processes. 

Verification of work flow-based applications 

The underlying business process of non-workflow-based applications is, as 
outlined previously, deeply buried in the application itself. That means 
the business process and the application logic need to be tested 
together- In work flow-based applications, the business process and the 
programs implementing the activities are described separately. 

Testing workf low-based applications, therefore, is much simpler, since to 
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a large extent the testing of the business process can be done 
independently of the testing of the activity implementations. In fact, 
the testing of the business process can be done before the actual 
implementation of the application functions starts. As soon as testing 
of the business process is con^leted^ the interfaces for the control and 
most of the data relevant to the data flow are defined. 

The verification of workf low-based applications is performed in three 
phases, as shovm in Figure 5. The first step checks the process models 
for correctness. It includes checking to see whether the process 
structure, the invocation of programs^ and the distribution of work are 
correct- 

What needs to be checked and what can be checked for correctness of the 
process structure depends on the underlying process meta-model. 29 In the 
case of IBM FlowMark, for example, no checks need to be performed for 
loops since the process graph is a directed, acyclic graph. But two 
basic items always need to be checked. First, the passing of data from 
one activity to a subsequent activity must be correct and complete. 
Incomplete data lead to an incorrect evaluation of transition conditions, 
resulting in incorrect control flow and the passing of incorrect data to 
invoked programs or subprocesses . This item is particularly important 
for activities where a field in the input container is the target of 
multiple data connectors. Second,^ the transition, exit^ and start 
conditions must be semantically correct. 

The invocation of programs includes not only defining the proper 
invocation mechanism, but also properly passing data to the program and 
returning the appropriate data. 

A staff assignment identifies the set of people who must perform the 
appropriate task for each activity. Therefore, checking the correct work 
distribution involves not only seeing whether work is assigned to the 
right person, but also obtaining a first hint of whether the work is 
distributed properly. 

IBM FlowMark, for example, uses the technique of animation to help the 
process modeler perform this task. 30 It offers two modes, process 
debugging and the regression test. In the process debugging mode, the 
user navigates through the process model step by step. In the regression 
test mode, a stored script is automatically executed. The execution of 
the appropriate programs is simulated by displaying the input to be 
passed to the program and allowing the user to fill in the data to be 
returned by the program; thus, the programs must not have been 
implemented. The advantages of the animation are: (1) the identical 
presentation of the process model is used for modeling and debugging, (2) 
the visualization of control and data flow as well as the status display 

of activities allow design errors to be easily recognized, <3) animation 

can be done at any time, even if the process model is syntactically and 
semantically incorrect, (4) the work list of the process participants is 
visualized, and (5) the interaction in the process debugging mode can be 
stored to be used in regression test mode. 

In a second step, the process models are checked to see whether the 
organization as well as the IT infrastructure is capable of supporting 
the nund:>er of expected process instances , The technique used for this 
phase is sim\ilation: analytical and discrete. 

Simulation is based on metrical information that is collected for the 
process and the activity level and is mostly provided by the business 
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analyst- The process-level information includes the number of processes 
started, the probability that a certain branch is taJcen in the process, 
the probability that an activity is repeated, and the size of the process 
input and output containers. For the activity, it includes 
process-related information, such as the average time reqtuired to perform 
the activity, including idle and wait tirae- 

Analytical simulation is used to calculate the required people and 
con5)uter resources. If this turns out to be insufficient, any further 
analysis is superfluous. The sufficiency of computer resources is 
evaluated by determining the CPU load on servers and clients, the network 
traffic caused by server-to-server communication and data passed from one 
activity to the next, and the transaction load on the database and the 
transaction processing (TP) monitors. People resources are calculated by 
determining the amount of time required to perform the activities. The 
information derived for a process is then combined with the resource 
information derived from other processes. 

Discrete simulation is used to determine the impact of multiple process 
instances competing for the same resources . Input to the simulation 
consist of scenarios describing which process models should be used in 
the simulation. The simulation component uses this information to drive 
the navigation engine of the workflow manager with the proper requests, 
such as process start and activity completion. The results are written 
to a file that serves as input to "create the simulation results. Typical 
results are the probability distribution of process execution time and 
transaction rates. 

The results of analytical and discrete simulation can be used to tune the 
accessed databases. Using the activity invocation rates and the database 
accesses of the activity implementations, one can determine the number 
and types of structured query language (SQL) calls against each database. 
This information and the current or estimated size of the databases 
provides sufficient input to the physical database designer to determine 
the proper database characteristics. Furthermore, it allows a user to 
determine how the size of the database changes over time. Collecting 
additional information, such as the distribution of keys, allows, for 
exan??le, the detection of hot spots in tables - 

The process perfoznanc« monitor, by analyzing the audit trail, helps to 
obtain information relevant to the process parfoxmanoe, such as the 
average process duration, idle time for activities, or excessive 
notifications when work is not performed in a timely manner. 

A sample scenario 

This section discusses some of the components of the development 
environment in more detail and outlines how those con^onents could 
collaborate. IBM products have been selected for purposes of 
illustration. The components being explored further are the business 
modeling tool, the build- time component of the workflow management 
system, and the visual builder. The corresponding produces are the IBM 
Business Process Modeler, FlowMark, and VisualAge C++*, respectively. 

A simple loan process is used as a guide through the various components. 
The loan process starts when a customer contacts the bank and finishes 
when the customer receives the appropriate response from the bank, either 
a denial of the loan or the granting of the loan. 

Business modeling tool . The design of a business process can start, as 
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outlined earlier, with a business modeling tool. The IBM Business 
Process Modeler implements an extended version ot the IBM LOVEM 
methodology. LOVEM focuses on the interactions between the customer and 
the company. All information is captured via a graphical editor that 
supports the creation of two sets of diagrams: hierarchical structure 
diagrams and line of visibility charts. Hierarchical structure diagrams 
provide a hierarchical grouping of all relevant elements, such as 
processes, critical success factors, computer programs, organizational 
units, opportunity areas, problem areas, and line of visibility charts. 

There are four different types of line of visibility charts (LOVC) . The 
architecture IiOVC (ALOVC) provides an overall view of what the company 
does, together with the essential customers and the sequence of business 
processes. The Job LOVC (JLOVC) shows all activities of a job and 
provides the base for analyzing the efficiency of job porformanc*. The 
logical LOVC (LLOVC) provides a refinement of the ALOVC and shows the 
data flow between processes and subprocesses. The physical LOVC (PLOVC) 
shows the activities within a business process and how they arc performed 
by connecting activities to other activities or to document storage, 
office systems, and computer systems, for exeunple. 

The charts are organized into horizontal areas, called bands. In LLOVCs, 
a band represents a business function within the company^ such as 
personnel. It shows what processes are performed by each function and 
the relations between the processes in the form of data flows, which 
represent data that are generated from or required by the process. In 
PliOVCs and JLOVCs, a band represents organizational units and contains 
for each organizational unit the activities, tasks, systems, critical 
success factors, and other aspects of a business process and the 
relations between those items in the form of information flows . 
Information flows represent the flow of information^ but also of goods 
and controls. 

Figure 6 shows the PLOVC of the loan process. The horizontal bands 
represent the parties involved in the process; the customer, the loan 
officer, and the loan supervisor. The line between the customer and the 
coin>any is called the line of visibility. The manual and automation 
bands are used to describe how a particular activity is supported. When 
the activity is in the manual band, it is performed manually; when in the 
automation band, it is completely performed by a computer program; when 
on the line, it is performed by a computer system that interacts with the 
user. The system shown in the figure is used to collect loan information 
for a customer. Based on the amount of money involved, an assessment 
must be made by the loan supervisor. Finally, the customer receives a 
loan contract or rejection letter. 

Workflow build time. The business modeling information must now be made 
available to the workflow management system. As pointed out in the 
earlier subsection on business modeling, it is done via an interchange 
format. The business modeling tool converts the PLOVC of the loan 
process into FlowMark Definition Language, which is then imported into 
FloWMark, This process skeleton must then be enriched with information 
required during process execution, such as program names, staff 
resolution expressions, and data structures and data connectors. This 
type of information, which is related to information technology, is not 
collected during business modeling. The amount of information to be 
added depends on the amount and granularity of the information collected 
by the modeling tool. Because the activities specified with the business 
modeling tool are generally quite coarse-grained, as is the case with the 
IBM Business Process Modeler, they often need to be replaced by 
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subprocesses or a set of activities. Figure 7 shows the loan process 
after making these modifications with the FlowMark process model editor. 
The single system used in the PLOVC for managing loan information has 
been split into multiple smaller programs. The activity 
"CollectCustomerlnformatlon" obtains the customer number. If the 
customer is new, all customer information, such as the address, is 
collected in the activity "CollectCustomerData. " The next step, common 
again for all customers, is the collection of credit information, such as 
the amount of credit. 

It should be noted that the program could have been in¥>lemented as one 
large program. The decision to break up the program has been guided by 
the desire to extract control and data flow, in the spirit of workflow, 
to make future changes siitpler. The one possible disadvantage is the 
amount of time required by the workflow manager to navigate through the 
process graph, and it can be eliminated by compiling parts of the process 
graph. 31 Note explicitly that this function is not part of the delivered 
FloWMark product. 

When the credit amount is small, and the customer risk factor is low, the 
loan is accepted right away, and the activity "createAcceptanceliCtter" is 
started automatically. In the other case, as already shown in the PLOVC, 
management approval must be obtained. On the basis of what management 
decides, the loan is either grant.§d or denied* 

Testing of the application is performed using the animation facility of 
FlowMark, as described in the previous section. 

Visual builder. A visual builder, discussed earlier, is the preferred 
tool for constructing activity implementations. More information about 
IBM VisualAge can be found in References 23 and 32. 

Visual builders allow applications to be constructed from existing, 
reusable software components called parts. Parts are either visual or 
nonvisual. visual parts allow an application developer to easily 
construct sophisticated graphical end-user interfaces; nonvisual parts 
provide programming constructs such as accessing a database or 
maintaining a list or text strings. 

A part in VisualAge C++, for exaii?)le, is a software object iii?>lemented as 
a C++ class that supports a simple, standardiied protocol- This protocol 
supports the interconnection of parts to form higher- function parts or 
entire applications. The part interface is con^osed of three distinct 
features: attributes, actions, and events. These features correspond to 
a natural way of viewing parts (and objects in general) in terms of what 
properties (attributes) they have, what behaviors (actions) they can 
perform, and what unsolicited information (events) they can provide to 
other parts. 

The construction of the application is via the composition editor of the 
visual builder. The editor provides the capability to create the views 
for the application, to select the parts that implement the logic, and to 
make connections between the parts. 

The workflow management system provides an application interface so that 
the activity implementation can access the input and output containers of 
the activity. The construction of workf low-based applications via visual 
builders is siix«>lified through nonvisual parts for the input and output 
containers that wrap the latter. Reference 33 shows a method for 
creating those parts from the container structures. Figure 8 illustrates 
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Note that most of the features outlined in this section are not available 
in commercial systems. Because of the relevance sketched earlier^ we 
included this subject as an outlook to possible extensions of some 
commercial systems. 

A brief sketch of transaction models. For the reader's convenience, we 
provide a brief taxonomy of transaction models based on the duration of 
the underlying unit of work. More details on transaction models can be 
found in References 34 and 35- 

The fundamental concept in this area is the ACID paradigm, which enforces 
the collection of operations to behave as follows: 

o Either all of them are applied to the system or none of them at all 
(atomicity) . 

o They lead to a new valid state of the system (consistency) - 

o They do not affect (until explicitly made visible) operations outside 
the collection (Isolation). 

o They are not undone because of any later system failure (durability) . 

Tremendous work has been performed' in the past to figure out how the 
structure and behavior of units of work correlate with their average 
duration. As a result, different transaction models have been proposed. 

What is traditionally subsumed under the notion of a transaction is a 
flat ACIDic unit of work with a duration of about a second. Typical 
application areas for which this notion of a transaction is best suited 
are telephone switching, flight reservations, or accounts handling. 
Units of work that last for tenths of a second when using the flat ACID 
paradigm (like an order entry application) resulted in the invention of a 
transaction model (close-nested transaction) that allows structuring the 
overall transaction as a tree of sub transactions, thus improving 
parallelism within the encoR^assing unit of work and enhancing its 
overall response time. When huge collections of data items have to be 
manipulated, as in batch updates, durations between minutes and hours are 
found. In this situation, AClDicity results in inappropriate concurrency 
and recovery behavior that means backing out all modifications if the 
last manipulation fails. That led to techniques like minibatches and 
savepointing. Incidentally, these techniques require special programming 
by the application programmer, such as persistently tracking the state of 
the transaction. They are, therefore, not suitable in more complicated 
applications such as trip reservation systems where multiple databases 
might be accessed and operations can only be undone semantically by 
invoking special compensation actions. Transaction models such as 
open-nested transactions, which assume a manual invocation of 
condensation, or those such as Sagas, which support system-invoked 
condensation, circumvent such restrictions. When units of work last for 
days, weeks, or even much longer, an appropriate transaction model must 
deal with (planned and unplanned) system shutdowns without losing control 
of the boundary of the unit of work, must facilitate partial backout, or 
must cope with different users cooperating in the unit of work. The 
condensation spheres transaction model to be described shortly is 
targeted toward these conditions. 

Two categories of transaction functions. When analyzing the exploitation 
of workflow technology with respect to extended transaction processing. 



Received from < 9149621973 > at 11/3/03 2:28:17 PM [Eastern Standard Time] 





Nov 03 03 02:09p 



ANNE V.DOUGHERTY 



9149621973 



p. 20 



Page 18 of 24 



the following two independent categories of features can be identified. 

o The WEKS should allow for coupling activities of business processes 
with respect to their semantic success. An activity is successfully 
completed semantically if the work has been finished as it was intended 
by the process modeler. An activity such as sending an e-mail note, 
for exart^le, has successfully completed semantically when the note has 
been written and sent. If the work associated with an activity cannot 
be successfully con?)leted semantically, or when the results produced by 
a collection of activities are detected to be incorrect, the WFKS 
should undo the already-processed coupled activities and start the 
affected parts of the business process again. Basically, this is the 
requirement for a compensation-based partial backward recovery 
facility, which is referred to as compensation spheres. Work is undone 
either by automatically deriving the business process representing the 
reverse execution of the part to be undone or by starting a predefined 
business process to repair the situation as described below. 

o The WFMS should allow for coupling transactional activities, meaning 
activity iinplementations that represent transactions in the classical 
sense, with respect to their transactional outcome. If one of the 
transactions fails (in the sense of the ACID paradigm) , the whole 
collection must be aborted. Basically, this requires the ability to 
declare the atomicity of collections of activities (via an atomic 
commit protocol, or via close-nested transactions, etc.). Such 
collections are referred to as atomic spheres. A WFMS can manage an 
atomic sphere by dynamically creating a common transactional context 
when entering the atomic sphmrm and initiating the atomic commit 
protocol for leaving the atomic sphere (see discussion on atomic 
spheres below) . 

Compensation spheres. It is the nature of business processes that 
activities are generally long running (especially in tolerating system 
shutdowns) and must be thus interruptible, and that they often 
externalize intermediate results. Obviously, the same is true for 
business processes themselves. Furthermore, a business process usually 
contains collections of activities that are semantically coupled In the 
sense that either all coupled activities must be perfontied successfully 
or the work associated with the activities must be backed out to allow 
the business process to continue correctly. In this context, the usual 
transaction models (generally realized via mechanisms like locking, etc.) 
obviously do not apply. 

A transaction model, called compensation spheres, suitable for coping 
with these requirements has been introduced in Reference 9, and the 
reader is referred to that publication for in-depth details. A 
compensation s:]^ere is any collection of activities of a process model 
such that finally either all activities must have run successfully, or 
all activities must have been compensated. An activity that has not run 
is considered to be compensated via NOP (no operation, i.e., nt)thing is 
performed) ; that means in practice only the activities of the 
compensation sphoro that were activated are physically coii9)ensated. 
Furthermore, each activity within a compensation s^^r* or the whole 
conqpensation sphere itself is associated with an activity called its 
compensating activity. A compensating activity might be a program or 
again a process model. The basic mode of undoing a compensation sphere 
is to automatically schedule the compensating activities of all 
activities within the sphere in an order that is the "reverse" of the 
order in which the proper activities of the compensation spihere have run. 
of course, staff resolution does also apply to the scheduling of 
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compensating activities. 

Figure 9 shows a process model for trip reservations. After the client 
plans the itinerary^ it is submitted to travel agents who will try to 
make the corresponding reservations for hotel rooms, rental cars, and 
flights. To speed up the reservation process, these activities can be 
worked on in parallel by different people. If all reservations have been 
made, the resulting schedule is printed and sent to the client. If one 
of the travel agents fails to make an appropriate reservation (for 
example, there is no hotel room available for part of the itinerary), 
compensating activities are scheduled to cancel the reservations already 
made. 

Many different parameters affect actual behavior when backing out a 
compensation sfihere. For example, you can specify whether condensation 
should be performed and whether work within affected process branch (es) 
should continue at the entry points of the compensation spheres, whether 
some administrative actions have to take place, or whether the control 
flow simply has to continue at the entry points of the compensation 
spheres without performing any compensation. Furthermore, coit^ensation 
spheres can become a target of cascading backouts, and backout is not 
only performed in a "discrete" manner by running the compensating 
activities associated with the proper activities, but also in an 
"integral" manner by singly running a compensating activity (which can 
again be defined as a process model) that is directly associated with the 
affected compensation sphere itself. 

Compensation spheres will provide tremendous benefits from a cost and 
re-engineering point of view in automating compensation. Many 
enterprises have special departments completely dedicated to 
compensation. When erroneous situations are detected, members of these 
departments are informed, and they use compensation techniques to 
manually repair the broken resources. Long- running transactions will 
typically be modeled as compensation spheres. 

Atomic spheres. As was described in the third section, activity 
implementations are canonical candidates for reuse. It is a well-known 
proposition from software engineering that components built for reuse 
should have weak couplings. In other words, the number and complexity of 
connections between such components should be minimized. The following 
example demonstrates this constraint for an activity inclement a tion 
dealing with recoverable resources. Because it is striving for a high 
degree of reusability, it consequently must not assume the management of 
any transaction boundaries. In workf low-based applications, it must, 
therefore, be possible to establish transaction boundaries outside of the 
activity implementation. 

Let us assume two activity implementations, one of which WITHDRAWS an 
amount from a particular account, the other deposits an amount to an 
ACCOUNT. Note that this could be nicely implemented as two methods of an 
account business object- Since a customer may sometimes wish to put 
money into his or her account, or sometimes wish to withdraw money from 
the account, it is seductive for the iiciplementer of the DEPOSIT as well 
as the WITHDRAW activity implementation to establish a separate 
transaction boundary that will commit or roll back the performed work. 
The transfer of money from one account to another could now reuse both 
the DEPOSIT as well as the WITHDRAW activity in^lementation by invoking 
WITHDRAW for the first account and DEPOSIT for the second. It may happen 
by accident that the WITHDRAW activity implementation commits, but 
DEPOSIT does not leave the overall "transaction" in a consistent state - 
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This reveals the necessity of being able to establish transaction 
boundaries separate from the activity implementations. It is the WFMS 
that could issue independent commit requests for WITHDRAW and DEPOSIT in 
the first scenario but could issue a "global commit" in the second 
scenario . 

Writing components without any assumptions on transaction boundaries will 
enhance their reusability. This observation is reflected in OMG's Object 
Transaction f rameworJc, 36 which provides access to transaction managers 
and resource managers- It allows WFMSs to manage transaction boundaries. 
For that purpose we introduce the concept of an atomic sphare. An atomic 
sphere is a set of activities each of which is "transactional" in the 
sense that they access recoverable resources. Furthermorcr the contro-l 
flow between two transactional activities of an atomic sphere must not 
leave the atomic sphere and enter it again at a later point in time. The 
WFMS will make sure at run time that either all activities that have run 
within the atomic sphere are committed or all have aborted (note that due 
to different heuristic decisions of two participants37 the semantics 
cannot be enforced) . In the second scenario of the above example, the 
WITHDRAW and DEPOSIT requests are defined as an atomic ^here so that the 
WFMS will ensure a consistent end-of -transaction processing. 

Note the subtle but important difference to distributed transactions: 
Based on the syntactic specification of an atomic sphere within a process 
model, it is the WFMS that establishes the transaction boundaries 
dynamically (dependent on the execution context of the workflow) . Thus, 
the activity inclement at ion programmer is freed from this concern. In a 
raw distributed transaction environment, programmers have to deal with 
it, 38 

At the operational level, each implementation of an activity within an 
atomic sphere is required to exploit only resource managers in the sense 
of Reference 38 and does not provide its own end-of-transaction 
processing. 

Atomic spheres might become very helpful from a technical point of view. 
They permit, for example, the tying together of independent (and, in the 
above sense, well -behaving) transactions that are manipulating databases 
in such a way that if one transaction fails, the others are aborted, too. 
It significantly sin^lifies the task of managing the associated 
transactions. Nevertheless, atomic spheres should be exploited very 
selectively because of their operational drawbac)cs« They use a two-phase 
commit protocol, which inherently strives toward holding locks until the 
end of the encompassing atomic sphere, thus reducing concurrency. In 
addition, many messages have to be sent so that there is a consensus to 
the outcome of all participating transactions. Both locking and message 
traffic inipact performance. Therefore, only a few short running 
transactional activities should be bound into an atomic sphen^^ 

Mixing compensation spheres and atomic spheres. From a modeler's, 
perspective, compensation spheres and atomic spheres are overlaying the 
model of a business process. The result is that modelers will specify 
the processes of an enterprise and identify collections of activities 
that have to be explicitly undone in case of an erroneous situation {in 
the sense of being repaired via a dedicated business process) and resumed 
afterwards. They will also specify collections of transactional 
activities that are undone (in the sense of simply restoring the 
manipulated resources to their original state) in case one of these 
transactions fails. The sphere definitions are stored in the WFMS with 
the models of the business processes^ resulting at run time in business 
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transactions or extended transactions/ respectively, managed by the WFMS. 
Summary 

We have shown that the basic routing features of a wms allow the 
extraction of all flow information from an application similar to a DBMS 
that provides the means to extract all proper data management functions 
from an application. As a result, the application is both 
data-independent and flow- independent. Such a worJcf low-based application 
consists of a process model and a collection of activity implementations. 
The activity inclement at ions become a subject for reuse to be exploited 
in different process models. We have shown how potential transactional 
features of a WFKS could further enhance the reusability of activity 
in^lementations. The task of writing activity implementations is reduced 
to realizing proper application logic or business functions. This task 
can be further eased dramatically by exploiting visual builders, reusable 
parts, and business objects. 

Starting from an application developer's wish list, we have proposed an 
application development method and environment that facilitates the 
design, implementation, and testing of workf low-based applications. A 
three-phase approach, which includes animation, simulation, and 
monitoring, helps to verify the workfloW-based application without an 
extensive setup of con^ilex environments. A sample scenario showed 
partially how such an environment '"could be used by an application 
developer. 
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